

REMARKS 



Applicants respectfully request that the above-identified application be re-examined. 

The August 28, 2003, Office Action ("Office Action") rejected all of the claims (1-23) of 
the above-identified application. Claims 1-5, 7-9, 12, 20, and 22 were rejected under 35 U.S.C. 
§ 102(e) as being anticipated by the teachings of U.S. Patent No. 6,233,624 (Hyder etal.). 
Claims 6, 10-11, 13-19, 21, and 23 were rejected under 35 U.S.C. § 103(a) as being unpatentable 
in view of the teachings of Hyder etal. taken in view of the teachings of U.S. Patent 
No. 5,978,815 (Cabrera etal.). Independent Claims 1, 13, and 20-23 have been amended to 
more clearly point out and distinctly claim the subject matter applicants regard as their invention. 
A draft set of the proposed claim amendments were submitted to the Examiner for consideration 
on November 4, 2003. On December 15, 2003, applicants' undersigned attorney briefly 
discussed by telephone the amended claims with Examiner Ho, who suggested that applicants 
submit in writing the reasons why applicants believe that the claims are allowable. Applicants 
thank Examiner Ho for the courtesy shown during the telephone conversation. This submission 
is in accordance with the Examiner's suggestion. 

Prior to discussing the reasons why applicants believe that the amended claims in this 
application are allowable, a brief discussion of the present invention, followed by a brief 
discussion of the cited and applied references, is presented. The following discussion of 
applicants' invention and the cited and applied references is not provided to define the scope or 
interpretation of any of the claims in this application. Instead, these discussions are provided to 
help the United States Patent and Trademark Office ("the Office") better appreciate important 
claim distinctions discussed thereafter. 

Summary of the Invention 



The present invention addresses one of the shortcomings of supporting a kernel mode 
driver that provides management and diagnostic data in enterprise networks, namely, the burden 
associated with the need for manufacturers to independently develop software methods and 
functions to incorporate into device drivers in order to support a device driver monitor and 
control management system, such as the Windows Management Instrumentation ( M WMI") 
system. A device driver monitor and control management system, such as the WMI system, 
monitors information provided by and actions performed by device drivers and issues messages 
to device drivers. 

The prior art need for manufacturers to independently develop software methods and 
functions to incorporate into device drivers has created a burden shared by every developer of 
device drivers intended to be used with a device driver and monitor control management system. 
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Additional time is required for each developer to produce both the code specific to the 
developer's device and the code specific to the device driver and monitor control management 
system. Further, because similar code is often included in the device drivers that support the 
device driver monitor and control management system, functionally identical code is often 
loaded into memory by several drivers. The result is an inefficient operation that requires more 
overhead than necessary to support the device driver and monitor control management system. 
Overall system performance may suffer. Also, the likelihood of encoding errors or "bugs" is 
increased due to many disparate developers creating code that performs substantially the same 
function. 

The present invention addresses the above-described needs and disadvantages by 
providing a set of common software routines that may be accessed by device drivers in support 
of a device driver and monitor control management system that monitors information provided 
by and actions performed by device drivers and that issues messages to device drivers. The set 
of common routines includes typical routines that would ordinarily be executed by device drivers 
designed to function with such a device driver and monitor control management system. The 
common routines reside in a library, dynamically accessible by the device drivers. When a 
device driver receives a message from such a device driver monitor and control management 
system, if appropriate, the device driver passes the message to the library to be handled in a 
common manner. In this manner, the developers of device drivers that support the device driver 
monitor and control management system need develop only the code necessary to support any 
unique features or data storage of the hardware associated with the device drivers. The result is 
shortened development time and fewer programming errors. In addition, the overall system 
performance may be improved because fewer instances of similar code are loaded in memory to 
support the device driver monitor and control management system. The present invention is 
particularly advantageous in enterprise networks, i.e., networks that include multiple devices, 
such as printers, fax machines, etc., that interact with multiple driving sources, such as 
computers, work stations, etc. 

One exemplary embodiment of the present invention provides an extension to a device 
driver operating in kernel mode. This exemplary embodiment allows instrumentation data, such 
as data to configure device settings and supply event notification from device drivers, to pass 
between user and kernel mode. Such data passage allows a device driver monitor and control 
management system that monitors information provided by and actions performed by device 
drivers and that issues messages to device drivers to access device drivers, even if they are kernel 
mode drivers. Device driver monitor and control management system access is provided by a set 
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of common software routines that may be accessed by device drivers in support of the device 
driver monitor and control management system. The common routines include typical routines 
that would ordinarily be executed by device drivers designed to operate with a device driver 
monitor and control management system that monitors information provided by and actions 
performed by device drivers and that issues messages to device drivers. The common routines 
reside in the common driver library accessible by the device drivers. When a device driver 
receives a message from the device driver monitor and control management system, if 
appropriate, the device driver passes the message to the library to be handled in a common 
manner. 

In addition to the other advantages described above, the use of common routines stored in 
a library allows the stored routines to be modified without affecting the related drivers so long as 
each driver's interface to the library is maintained. 

U.S. Patent 6.233.624 (Hvder et aU 

Hyder et al. provides a system for incorporating a link layer intermediate driver into a 
data flow path in a computer operating system. The data flow path is a path of execution that is 
traversed through a network protocol stack. The network protocol stack defines a data flow path 
through which data is passed between a transport layer and a physical device connected to a 
network. Generally, a network protocol stack comprises a transport layer driver, one or more 
link layer intermediate drivers, and a link layer device driver interfacing with the physical 
hardware or device. The link layer intermediate driver receives data and returns processed data 
through an abstract interface while a link layer device driver is comprised of an interface with the 
abstract interface and a separate interface with the physical device. The abstract interface is 
comprised of a function library, which handles many of the details involved in managing 
synchronous and asynchronous communications across a network. The abstract interface also 
provides a library of functions for interfacing with the kernel mode of an operating system. 
Device drivers, therefore, need only perform hardware-specific operations needed to manage a 
particular piece of hardware or physical device. In contrast, traditional drivers inherently 
incorporate most of the above functionality, which makes such device drivers much harder to 
write to and debug, and these device drivers often operate slower. 

Essentially, Hyder et al. discloses providing a driver library separate from a device driver. 
However, as more fully discussed below, Hyder et al. does not disclose, teach, or suggest a 
device driver monitor and control management system that monitors information provided 
by and actions performed by device drivers and that issues messages to device drivers, let 
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alone such a device driver monitor and control management system in communication with 
device drivers. 



U.S. Patent 5,978,815 (Cabrera et aU 

Cabrera etal. purportedly discloses a model where a plurality of drivers or client 
processes cooperate to fulfill an input/output ("I/O") request. The drivers or data managers may 
have a layered relationship to each other such that each is responsible for processing a particular 
portion of an I/O request. Information may be passed from one driver to another driver using I/O 
request packets ("IRPs") so that all drivers cooperate to fulfill an I/O request. 

Like Hyder etal., Cabrera etal. does not disclose, teach, or suggest a device driver 
monitor and control management system that monitors information provided by and actions 
performed by device drivers and that issues messages to device drivers. 

Rejection of Claims 1-5, 7-9, 12, 20 and 22 Under 35 U.S.C. § 102(e) 

As noted above, independent Claims 1 , 20, and 22 have been amended to more clearly 
point out and distinctly claim the present invention. For the reasons set forth below, applicants 
respectfully submit that the 35 U.S.C. § 102(e) rejection of Claims 1, 20, and 22 and the claims 
dependent from Claim 1, listed above, particularly as amended, is clearly in error, should be 
withdrawn, and these claims allowed. These claims are clearly not anticipated by Hyder et al. 
More specifically, as an example, as amended, Claim 1 reads as follows: 

1. A computer-readable medium having computer-executable 
components, comprising: 

a device driver configured to provide information and perform actions 
associated with a hardware device; and 

a driver library containing software routines for making the information 
provided by and the actions performed by the device driver accessible to a device 
driver monitor and control management system that monitors information 
provided by and actions performed by the device driver and that issues messages 
to the device driver, the software routines of the library being accessible by the 
device driver to handle messages issued to the device driver by the device driver 
monitor and control management system. 

Claim 1, as amended, recites a "device driver monitor and control management system 
that monitors information provided by and actions performed by the device driver and that issues 
messages to the device driver." Similar language has been added to Claims 20 and 22. Hyder 
et al. has no teaching or suggestion of such a device driver monitor and control management 
system, much less a device driver monitor and control management system that monitors 
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information provided by and actions performed by a device driver and that issues messages to 
the device driver. Applicants submit that the Office Action's conclusion that TRANSPORT 132, 
FIGURE 2, is a teaching of a device driver monitor and control management system of the type 
recited in independent Claims 1, 20, and 22 is clearly in error. More specifically, applicants 
respectfully submit that TRANSPORT 132 is clearly not a device driver monitor and control 
management system that monitors information provided by, and actions performed by, a device 
driver and that issues messages to a device driver. In this regard, attention is directed to 
Column 5, lines 53-59, of Hyder et al. which reads as follows: 

A transport layer driver 132 receives data destined for dispatch across a network 
via hardware or physical devices such as physical devices 152 and 154. Transport 
layer driver 132 performs packetization and formatting of bulk data into packets 
compatible for transfer across a network. Transport layer driver 132 is 
responsible for implementing a specific network protocol such as TCP/IP or 
IPX/SPX. 

In other words, TRANSPORT layer 132 simply performs bulk data formatting and packets the 
formatted data into packets compatible for transfer across a network. Transport layer 132 is not 
a device driver monitor and control management system, much less a device driver monitor and 
control management system that monitors information provided by and actions performed 
by a device driver and issues messages to a device driver as recited in Claims 1, 20, and 22. 
As a result, applicants respectfully submit that Hyder et al. does not teach or even suggest all of 
the recitations of Claims 1, 20, and 22. Because Hyder etal. does not anticipate these claims, 
applicants further submit that the rejection of Claims 1, 20, and 22 under 35 U.S.C. § 102(e) is 
clearly in error, request that this rejection be withdrawn, and Claims 1, 20, and 22 allowed. 

As Claims 2-5, 7-9, and 12 all depend from allowable Claim 1 and, thus, are submitted to 
be allowable for at least the reasons noted above. 

Claims 2-5, 7-9, and 12 all contain additional recitations that further distinguish them 
from the teachings of Hyder et al. and, thus, are submitted to be allowable for additional reasons. 
For example, Claim 7 recites that a unique software routine (added in Claims 2 and 3, the claims 
from which Claim 7 depends) "is configured to execute a method associated with the information 
associated with the hardware device, the method being operative to pass additional information 
between the device driver and the device driver monitor and control system or perform a certain 
action." There is no teaching, disclosure, or suggestion in Hyder et al. of a software routine that 
is configured to execute a method associated with the information associated with the hardware 
device, and operative to pass additional information between the device driver and a device 
driver monitor and control management system that performs the functions recited in Claim 1 . 
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Hyder et al.'s purported teaching of communication between drivers (Column 6, lines 13-48) is 
not a teaching or suggestion of communication with a device driver monitor and control 
management system. Hyder et al. merely teaches that one driver may pass a message to another 
driver. There is no hint in Hyder et al. of any device driver monitor and control management 
system, much less a device driver monitor and control system that monitors information provided 
by and actions performed by a device driver and that issues messages to a device driver, or of 
passing additional information to such a device driver monitor and control system, as recited in 
Claim 7. Accordingly, Claim 7 and its dependent claim, Claim 8, are submitted to be allowable 
for this reason as well. 

Rejection of Claims 6. 10-11, 13-19, 21, and 23 Under 35 U.S.C. § 103(a) 

Independent Claims 13, 21, and 23 have been amended to more clearly point out and 
distinctly claim the present invention. For the reasons set forth below, applicants submit that the 
35 U.S.C. § 103(a) rejection of these claims, and the claims dependent from Claim 1 listed 
above, particularly as amended, is clearly in error, should be withdrawn, and these claims 
allowed. Neither Hyder et al. nor Cabrera et al., taken alone or in combination, teaches or 
suggests the subject matter of these claims. More specifically, by way of example, as amended, 
Claim 13 reads as follows: 

13. A computer-readable medium having computer-executable 
instructions for providing management information to a device driver monitor and 
control management system that monitors information provided by and actions 
performed by the device driver and that issues messages to the device driver, 
which, when executed, comprise: 

receiving an input/output request packet ("IRP") message from the device 
driver monitor and control management system, the IRP message including 
instructions regarding data maintained by an instrumented hardware device; 

passing the IRP to a driver library containing software routines for 
handling the instructions of the IRP message; and 

handling the IRP message by the driver library. 

As already noted above with regard to Claim 1, Hyder et al. does not teach, disclose, or 
suggest a device driver monitor and control management system that monitors information 
provided by and actions performed by a device driver and that issues messages to a device 
driver. Thus, Hyder etal. does not teach, suggest, or disclose providing management 
information to such a device driver monitor and control management system. Nor does Cabrera 
etal. teach, disclose, or suggest this subject matter. In this regard, applicants specifically 
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disagree with the Office Action's assertion that Cabrera et al.'s "client process" is a management 
system. Even if correct, which applicants specifically deny, Cabrera et al.'s "client process" is 
not a device driver monitor and control system that monitors information provided by and 
actions performed by a device driver and that issues messages to a device driver . 

No reasons why it would have been obvious to combine the teachings of Hyder et al. with 
the teachings of Cabrera et al. are presented in the Office Action, and applicants maintain that 
there is no motivation to combine such teachings. Further, even if combinable, which applicants 
deny, the resulting combination would not anticipate the recitations of independent Claims 13, 
21, and 23 for the reasons discussed above with respect to Claims 1, 20, and 22. None of the 
cited and applied references discloses, teaches, or even remotely suggests receiving an 
input/output request packet ("IRP") message from a device driver monitor and control 
management system that monitors information provided by and actions performed by a device 
driver and that issues messages to a device driver as recited in Claims 13, 21, and 23. As neither 
Hyder et al. nor Cabrera et al., alone or in combination, teaches, discloses, or suggests any IRP 
message from or to such a device driver monitor and control management system, Claims 13, 21, 
and 23 are submitted to be allowable. 

As Claims 14-19 all depend from Claim 13, Claims 14-19 are submitted to be allowable 
for at least the reasons noted above. Additionally, Claims 6 and 10-11 are submitted to be 
allowable as they depend from Claim 1 , which is submitted to be allowable for the reasons noted 
above. 

Furthermore, Claims 6, 10-11, and 14-19 include recitations that further distinguish them 
from the teachings of Hyder et al. and Cabrera et al. and, thus, are submitted to be allowable for 
additional reasons. For example, Claim 11, which depends from Claim 1, recites "the driver 
library is further configured to receive, from the device driver, an identifier for a particular IRP, 
to execute a particular software routine related to handling the IRP and to return to the device 
driver monitor and control management system any information received from the hardware 
device as a result of handling the IRP" [emphasis added.]. As noted in a prior response, neither 
Hyder et al. nor Cabrera et al. teaches, discloses, or suggests returning to a device driver monitor 
and control management system any information retrieved from a hardware device, regardless of 
the form of the information. Accordingly, Claim 1 1 is submitted to be allowable for this reason 
as well. 

As a further example, Claim 19, which depends from Claim 18 (which depends from 
Claim 13) recites "the driver library is further configured to format data received from the device 
driver in a format consistent with the device driver monitor and control management system." 
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Hyder et al. merely teaches "decoding and branching to the applicable operative procedure." 
Nowhere does Hyder et al. teach data formatted into a format consistent with a device driver 
monitor and control management system that monitors information provided by and actions 
performed by a device driver and that issues messages to a device driver. As neither Hyder et al. 
nor Cabrera et al. teaches, discloses, or suggests data formatted into a format consistent with 
such a device driver monitor and control management system, Claim 19 is submitted to be 
allowable for this reason as well. 

CONCLUSION 

In summary, applicants submit that Claims 1-23 are clearly allowable in view of a lack of 
teaching or suggestion of a device driver monitor and control management system that monitors 
information provided by and actions performed by a device driver and that issues messages to a 
device driver in combination with the other recitations of these claims. 

In view of the foregoing remarks, applicants submit that the present application is now in 
condition for allowance. Reconsideration and reexamination of this application, as amended, 
allowance of the rejected claims, and passage of the application to issue at an early date are 
respectfully solicited. If the Examiner has any questions or comments concerning this 
application, the Examiner is invited to contact the applicants' undersigned attorney at the number 
below. 

Respectfully submitted, 

CHRISTENSEN O'CONNOR 
JOHNSO& KINDNES S PLLC 





Jary S. Kinflness 
'RegistratictaNo. 22,178 
Direct Dial No. 206.695.1702 

I hereby certify that this correspondence is being deposited with the U.S. Poatal Service in a sealed 
envelope as first class mail with postage thereon fully prepah^and addressed to the Comfn/ssioner for Patents, P.O. 
Box 1450, Alexandria, VA 22313-1450, on the below date. 
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